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EXAMINERS ANSWER 

This is in response to the appeal brief filed 07/02/04. 

(1) Real Party in Interest 

A statement identifying the real party of interest is contained in the brief. 

(2) Related Appeals and Interferences 

A statement identifying the related appeals and interferences, which will directly affect or be 
directly affected by or have a bearing on the decision in the pending appeal is contained in the 
brief 

(3) Status of Claims 

The statement of the status of the claims contained in the brief is correct. 

(4) Status of Amendments 

The appellant's statement of the status of amendments contained in the brief is correct. 

(5) Summary of the Invention 

The summary of the invention contained in the brief is correct. 

(6) Issues 

The appellant's statement of the issues in the brief is correct. 

(7) Grouping of Claims 

Appellant's brief includes a statement that claims of the following groups of claims stand or fall 
together and proved reasons as set forth in 37 CFR 1.192 (c) (7) and (c) (8). 
Group I: claims 1-7 and Group II: claims 8-14. 

( 8) Claims Appealed 

The copy of the appealed claims contained in the Appendix A to the brief is correct. 
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(9) Prior art of record 

The following is a listing of the prior art of record relied upon in the rejection of claims under 
appeal. 

(i) Wired For Speed: Efficient Routes in VRML 2.0, Woods, et. al., Silicon Graphics, VRML 97, 
ACM 0-89791-886, Monterey, CA 1997 pages 133-138 (Woods hereafter) 

(i) D7.2 Review of VRML and WWW Techniques, ACTS Project, COVEN-Collaborative virtual 
environments, pages 1-33 (COVEN hereafter) 

(10) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: Claims 1-14 are 
presented for examination. 

2. The following is quotation of 35 USC § 103(a), which forms the basis for all obviousness 

rejection, set forth in this Office action: 

(a) A patent may be not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and the 
prior art of record are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

3. Claims 1-14 are rejected under 35 U.S.C. §103(a) as being unpatentable over Woods et. al. 
Wired for Speed: Efficient Routes on VRML 2.0 in view of Coven-Collaboration virtual environment 
(referred to as Woods and Coven, respectively hereafter). 

4. Claims 1-14 are rejected under 35 U.S.C. 103(a) as being unpatentable over Woods et. al. 
(Woods) Wired for Speed: Efficient Routes on VRML 2.0 in view of Coven-Collaborative virtual 
environments (Coven), April 1997. 

Regarding claims 1 and 8, Woods teaches features of invention substantially as claimed; Woods teaches a 
system/method supporting communicating command information between a VRL nodes for sending 
(source) and receiving (destination) data via routes (section 2.1-2.2), said nodes include a player VRML 
browser (client) (abstract), interactive communication between said nodes consisting of request-response 
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model (section 2.3, i.e. client-server model) across a network (sections 2.2-2.3, client browser, configured 
to request data and receive arrival of requested data through a network) comprising: 

generating (firing) a command message associated with a user action or system event associated 
with streams containing scene description information (e.g. scene source nodes), command message 
including 

a command (eventln, see sections 1.1-2.2, command routes, section 4.1 commands, i.e. execute 
fields), a command descriptor (event fields, see section 4.1), and one of a source node route (command 
routes -rendering scene means, section 2.2-2.3) and 

a command node (execute event sink field i.e. command route node, see sections 2.1 and 4.1); 

wherein event source/sink routes support interaction between a source of the route and a 
destination of the route (see section 2.1, such as firing a 'TimeSensor" node scene in the interaction 
VRML model, interactivity-model is request-response between a requesting source and a responding 
destination nodes, section 2.3); and 

transmitting the command message upon occurrence of a user or system-triggering event (e.g. 
Touchsensor node scene, see 2.1 section, user or system events, see 2.2, source/sink route, user or system 
triggering event, message (request) transmission, message (response) receipt, using event source/sink 
routes, section 2.3, said messages to support said node scenes); however Woods does not explicitly teach 
a server route ("directly") associating a node with a command descriptor; 

Coven discloses a server route ("directly") associating a node with a command descriptor and a 
command node ("indirectly) associating a node with the command descriptor, wherein 

a command route (e.g. eventln SFFloat set_fraction) is executed when an event command is 
received on the execute field associated with a object node scene, e.g. from a TouchSensor node (section 
2.2.2 pages 6-7); 

the execution of command route is associated with a command descriptor (e.g. exposedField 
MFFloat key, exposedField MFVec4f key Value) (e.g. the orientation values are used by the object node 
scene to execute specified animated spinning effect) (Figs. 2-1 of section 2.2.2 and route commands of 
Fig. 2-2, pages 6-7); 

a server route command supporting server interaction is executed when event command is 
received on the execute field (e.g. field SFBool directOutput FALSE) associated with a object node scene 
("SFBool"), the command is communicated to the server as specified by the command descriptor to the 
server (e.g. exposedField MFString url) (see section 4.3.1 to 4.3.1.1, see Figs. 4-2 to 4-4 on pages 20-21) 
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exchanging the command message across a network upon the occurrence of a triggering event 
(section 4.4.2, trigger events on page 25, user process server interaction, section 4.3 on page 19-20, 
section 4.2.3.4 on page 19, communication over the network (Fig. 4-1, section 4.2.2 on page 14-16). 

It would have been obvious to one ordinary skilled in the art at the time the invention was made 
to utilize Coven's disclosure server route ("directly") associating a node with a command descriptor, 
motivation would be for supporting multi-user interaction among remote client and between clients and 
multiple suppliers via the MUtech, as indicated by Coven. 

Regarding claims 2-3, generating command message, discussed above is consistent with local 
interactivity model defined in MPEG-4 (COVEN: generation of commands, section 4.3.1 on page 20 and 
MPEG-4 data page 25). Also Admittance of prior art (MPEP § 2129) Applicant disclosure states: 
"MPEP-4 essentially uses two modes of interactivity: local and remote. Local interactivity can be fully 
implemented using the native event architecture of MPEG-4 interactivity can be fully implemented using 
the native event architecture of MPEG-4 BIFS (Binary Format for Scenes), which is based on the VRML 
2.0 ROUTEs design and documented in Part 1 of the MPEG-4 specification (Systems), see page 1, lines 
26-33 . It would have been obvious to one ordinary skilled in the art at the time the invention was made to 
utilize an interactivity model defined in MPEG-4, the new VRML 2.0 specification, enables much more 
dynamic and interactive environments supported by the convergence of these technologies; motivation 
would be to provide via MPEG-4 a real service on desktop application enhancing the tele-presence and 
shared virtual reality space technology. 

Regarding claims 4-5, the triggering event is a mouse clicks and wherein the triggering event is a timer 
signal (Woods, see 2.1 section). 

Regarding claims 6-7, command information is transmitted from the server to the client and wherein 
command information is transmitted from the client to the server (Woods, message between a provider 
node and a player VRML browser client node, request/response, see 2.1-2.3, request e.g. change state of 
current scene, response update and rendering requested scene) 

Regarding claims 9-14, the claim comprise the system in accordance to the method disclosed on claims 1- 
7, respectively, same rationale is applicable. 
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(11) Response to Arguments 

Regarding claim 1, it is argued (page 5) that the Woods reference does not disclose or suggest a route 
which targets a command descriptor, as required by claims 1 and 8, because the reference does not teach a 
command comprises information to be transmitted back to a server computer upon the occurrence of an 
associated event. 

In response to the above-mentioned argument, claims 1 and 8, have been carefully reviewed, 
however, it is not found where in theses claims there a recitation of; "a command comprises information 
to be transmitted back to the server computer upon the occurrence of an associated event". There is 
further in claim 1, no recitation of (< a route which targets a command descriptor", as argued. Thereby, in 
response to applicant's argument that the references fail to show certain features of applicant's invention, 
it is noted that the features upon which applicant relies are not recited in the rejected claim 1 and 8. 
Although the claims are interpreted in light of the specification, limitations from the specification are not 
read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). 
Furthermore, with respect to the argued claim limitation feature, claim 1 recites, "a server route for 
directly associated a node with the command descriptor". The claimed term "server ROUTE", as set forth 
by the specification is interchangeable with the term "command ROUTE node" (specs, page 8, lines 20- 
30), specifically, a "SERVER ROUTE" is a ROUTE node command with the ID of the target command 
descriptor specified (specs page 10, lines 2-10), described as a modification to the standard MPEG-4 
syntax (see Fig. 7). Specifically, "SERVER ROUTE" command is exemplified in its functionality and 
syntax is detail on in Fig. 9 of specification. 

The COVEN reference teaches a server route for associating a node with the command descriptor 
on Fig. 4.2 of page 20. The ROUTE command node script includes 

« exposedField MFString url », « field SFBool directOutput FALSE » 

here the object node scene i.e. "SFBool", the command route is executed when the event, e.g. the 
"eventOut or exposed field" on the execute field is executed, the execution by a browser execution engine 
involves communicating the command pointed by the command descriptor i.e. "MFString url" which 
contains a URL to command the command descriptor to a server. In this manner the prior art teaches a 
server route for associating a node with a command descriptor. 

Regarding item 2 on page 6, Relevant Case Law and Procedure(s) 

This section has been reviewed and considered by the examiner, however, it is not clear where is 
an argument set forth with respect to the applied reference(s). Specifically, it seems that none of the 
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applied references and/or claim limitation are mentioned. Thereby, it is not clear where or how is this 
section pertinent to instant application. 

Regarding Item 2: Issues on Appeal section, with respect to claims 1-7, specifically, it is argued the Wood 
reference fails to teach the client server model described on claim 1 . 

Woods teaches a browser implementing VRML 2.0 processing ROUTEs between various 
eventOut and eventslns in the scene, configured to generate events to sensors in the VRML scene graph 
and is configured to handle network generated events such as the arrival of requested data, the browser 
may received events from the network that may change the scene, and update the scene based on the 
events (section 2.2). The VRML 2.0 supports (client server modeling such as) a pull model in which 
messages are not sent until the recipient request data. Woods suggest a hybrid model (push & pull) 
including the transmission of data to update the scene to reflect the new changes on the scene based on 
the received event (as previously defined) using a pull model wherein the recipient of the message will 
request and received data (section 2.3). In this manner the prior art teaches the claimed (1) preamble's 
structure. Again, it noted that there are no client-server functions performed in the body of claim 1, to 
support the "client" "server" recitation entities in the preamble. 

The COVEN reference teach where the VRML specification supports an Open Community which 
supports a portable multi-user interactive Java API with VVRML prototype layer, wherein the multi-user 
world may operate on any server that supports Open Community (section 4.2.3 on page 16). To support 
low latency interaction, the world mode is replicated to multiple networked applications processes, 
propagating messaged over the network (section 4.2.3.2). This Open Community also supports hybrid 
models including a (client-server) environment, where centralized server processes are used to provide 
services, including servers to support uses with low connections a server which intercepts all 
communications to/from the users , this data in the world model can communicated using graphic models, 
sound and behaviors represented by object identified by URLs (section 4.2.3.3 on page 17-18). In this 
manner the prior art teaches the claimed (1) preamble's structure. 

Regarding claim 1, it is argued (page 6), that the Woods reference does not disclose or suggest a back- 
channel communication, which is required by the client-server arrangement of claims 1 and 8. 

In response to the above-mentioned argument, claims 1 and 8 have been fully reviewed. In this 
case, the preamble of for example claim 1, recites: a method for communicating command information 
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between a server and a client across a network in an interactive communication system, comprising the 
steps of: 

generating a command message including a command, a command descriptor, and one of a 
server route for directly associating a node with a command descriptor and a command node for 
indirectly associating a node with the command descriptor; and 

transmitting the command message across a network upon the occurrence of a triggering 

event 

It is noted that: (i) with respect to the claim's preamble, there is no recitation of a computer, i.e. a 
client computer nor a server computer in the claim, given the broadest reasonable interpretation inlight of 
the specification (see MPEP 2111), the "server" and "client" elements of the claim language are not 
required to be computers, they as well may be interpreted as process entities, (ii) with respect to the 
claim's preamble intended use, i.e. a method for communicating command information between a server 
and a client across a network in an interactive communication system, a recitation of the intended use of 
the claimed invention must result in a structural difference between the claimed invention and the prior art 
in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is 
capable of performing the intended use, then it meets the claim. In a claim drawn to a process of making, 
the intended use must result in a manipulative difference as compared to the prior art. See In re Casey, 
152 USPQ 235 (CCPA 1967) and In re Otto, 136 USPQ 458, 459 (CCPA 1963). 

It is noted that appellant is entitled to be his/her own lexicographer (MPEP §2111), the terms 
"client" and "server" may be broadly interpreted as processes, (claim does not require these to be 
computers), the term "interactive communication system", has been broadly interpreted as a system. 
Further, given the broadest reasonable interpretation to the claim's preamble and body it is not that there 
is no recitation of client and server functionalities, as argued. That is, there is no recitation of the features 
appellant relies on, i.e.: "a command comprises information to be transmitted back to the server 
computer" nor "a back-channel communication". 

In this case, the structure given patentable weight is in its broadest form, two process 
entities communicating across a network. The Woods reference teaches a browser architecture 
configured to issue a data request and receive requested data through a network, this is an 
explicit client server communication exchange (see sections 2.2-2.3), In this manner, the prior 
art teaches communication between a client and a server across a network. 
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Regarding claims of Group II (claims 8-14), it is argued or at least it seems that claim 8 is 
patentable for the same reasons claim 1 is allegedly patentable. 

In response to this section, it is noted that, appellant's grouping of claims states that the method 
and apparatus claims are separately patentable accordingly forming Groups I and II, indicating that these 
claims 1 and 8 of Groups I and II, respectively, do not stand or fall together (page 5). However, appellant 
explain that the claims of the group II are believed to patentable for the same reasons presented for Group 
I. Appellant has failed to provide a distinct and independent argument for each of the claims of Group I 
and II, as to why they are believed to be separately patentable. Because appellant's argument regarding 
the alleged patentability of the claims in Groups II is the same and solely based on arguments presented 
for Group I, therefore they are not independently patentable and fall together with claim 1 (see MPEP 
1.192(c) (7)). 

(12) Conclusion 

The ultimate determination of patentability with respect to this application, must be based on 
consideration of the entire record, by a preponderance of evidence, with due consideration to the 
persuasiveness of any arguments and any secondary evidence. In re Oetiker, 977 F.2d 1443, 24 USPQ2d 
1443 (Fed. Cir. 1992). The submission of objective evidence of patentability does not mandate a 
conclusion of patentability in and of itself. In re Chupp, 816 F.2d 643, 2 USPQ2d 1437 (Fed. Cir. 1987). 
Facts established by rebuttal evidence must be evaluated along with the facts on which the conclusion of a 
prima facie case was reached, not against the conclusion itself In re Eli Lilly, 902 F.2d 943, 14 USPQ2d 
1741 (Fed. Cir. 1990). In other words, each piece of rebuttal evidence should not be evaluated for its 
ability to knockdown the prima facie case. All of the competent rebuttal evidence taken as a whole should 
be weighed against the evidence supporting the prima facie case. In re Piasecki, 745 F.2d 1468, 1472, 223 
USPQ 785, 788 (Fed. Cir. 1984). Although the record may establish evidence of secondary considerations 
which are indicia of nonobviousness, the record may also establish such a strong case of obviousness that 
the objective evidence of nonobviousness is not sufficient to outweigh the evidence of obviousness. 
Newell Cos. v. Kenney Mfg. Co., 864 F.2d 757, 769, 9 USPQ2d 1417, 1427 (Fed. Cir. 1988), cert, 
denied, 493 U.S. 814 (1989); Richardson-Vicks, Inc., v. The Upjohn Co., 122 F.3d 1476, 1484, 44 
USPQ2d 1181, 1187 (Fed. Cir. 1997) (showing of unexpected results and commercial success of claimed 
ibuprofen and psuedoephedrine combination in single tablet form, while supported by substantial 
evidence, held not to overcome strong prima facie case of obviousness). 
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For the reasons above it is believed that the rejection should be maintained. 
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